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Abstract.  Much  work  on  security- typed  languages  lacks  a  satisfactory 
account  of  intentional  information  release.  In  the  context  of  confiden¬ 
tiality,  a  typical  security  guarantee  provided  by  security  type  systems 
is  noninterference ,  which  allows  no  information  flow  from  secret  inputs 
to  public  outputs.  However,  many  intuitively  secure  programs  do  allow 
some  release,  or  declassification,  of  secret  information  (e.g.,  password 
checking,  information  purchase,  and  spreadsheet  computation).  Nonin¬ 
terference  fails  to  recognize  such  programs  as  secure.  In  this  respect, 
many  security  type  systems  enforcing  noninterference  are  impractical. 
On  the  other  side  of  the  spectrum  are  type  systems  designed  to  accom¬ 
modate  some  information  leakage.  However,  there  is  often  little  or  no 
guarantee  about  what  is  actually  being  leaked.  As  a  consequence,  such 
type  systems  are  vulnerable  to  laundering  attacks,  which  exploit  declassi¬ 
fication  mechanisms  to  reveal  more  secret  data  than  intended.  To  bridge 
this  gap,  this  paper  introduces  a  new  security  property,  delimited  re¬ 
lease,  an  end-to-end  guarantee  that  declassification  cannot  be  exploited 
to  construct  laundering  attacks.  In  addition,  a  security  type  system  is 
given  that  straightforwardly  and  provably  enforces  delimited  release. 
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1  Introduction 

A  long-standing  problem  in  computer  security  is  how  to  verifiably  protect  the 
confidentiality  of  sensitive  information  in  practical  computing  systems.  One  of 
the  most  vexing  difficulties  is  that  realistic  computing  systems  do  release  some 
confidential  information  as  part  of  their  intended  function.  The  challenge  is  how 
to  differentiate  between  proper  and  improper  release  of  confidential  information. 

For  example,  it  is  possible  to  learn  a  small  amount  of  information  about 
a  user’s  password  by  attempting  to  log  in;  the  attacker  likely  learns  that  the 
password  is  not  the  one  guessed.  How  can  this  secure  system  be  distinguished 
from  an  insecure  system  that  directly  reports  the  entire  password  to  the  attacker? 
This  paper  proposes  delimited  release ,  a  new  definition  of  security  that  helps 
make  the  distinction. 

*  This  work  was  partly  done  while  the  author  was  at  Cornell  University. 


To  protect  confidentiality  within  a  computing  system,  it  is  important  to 
control  how  information  flows  so  that  sensitive  information  is  not  transmitted 
inappropriately  to  system  outputs.  One  way  to  control  these  flows  is  to  asso¬ 
ciate  a  security  level  with  information  in  the  system,  and  to  prevent  higher-level 
(more  confidential)  information  from  affecting  lower-level  (less  confidential)  in¬ 
formation.  Recently  there  has  been  much  work  embodying  this  approach  in  a 
language-based  setting  [37],  where  the  system  to  be  validated  is  a  program  and 
the  security  levels  are  types  in  that  program  [47, 19,  27,  2, 42, 45, 4, 38, 33,  39,  51, 
5,34].  A  program  written  in  this  sort  of  security-typed  language  is  considered 
secure  only  if  it  is  well-typed,  which  rules  out,  for  example,  assignments  from 
high-level  variables  to  low-level  variables. 

This  kind  of  static  checking  tends  to  be  very  restrictive,  preventing  practical 
programming.  Typically  these  languages  are  intended  to  enforce  some  version  of 
the  noninterference  [16]  security  property,  which  prevents  low-level  information 
from  depending  on  high-level  information.  Yet  many  practical  programs,  such  as 
the  password  checker  mentioned  above,  do  release  information.  Another  example 
is  aggregating  data  from  a  large  database  (such  as  an  employee  database)  to  com¬ 
pute  a  less  confidential  result  (such  as  the  average  salary).  And  sometimes  confi¬ 
dential  information  is  released  as  part  of  a  transaction  or  agreed-upon  protocol, 
such  as  when  information  is  purchased.  All  of  these  programs  violate  noninter¬ 
ference  and  would  be  rejected  by  the  type  systems  of  most  current  security-typed 
languages. 

Assuming  that  the  confidentiality  of  data  is  expressed  as  a  security  level, 
some  additional  mechanism  is  needed  in  order  to  express  programs  in  which 
there  is  an  intentional  release  of  information.  Some  security-typed  languages 
(e.g.,  [27,  33, 13])  have  therefore  added  a  declassification  mechanism  that  coerces 
the  security  level  of  information  downwards.  Declassification  serves  as  an  escape 
hatch  from  the  rigid  restrictions  of  security  type  systems,  but  it  (intentionally) 
violates  noninterference. 

A  question  that  has  not  been  addressed  satisfactorily  by  earlier  work  is  what 
security  guarantees  can  be  offered  in  the  presence  of  declassification.  Delimited 
release  is  such  a  guarantee.  Like  noninterference,  it  has  the  attractive  property 
that  it  defines  security  in  terms  of  the  program  semantics  rather  than  in  terms 
of  non-standard  mechanisms.  Thus,  it  controls  the  end-to-end  [40]  behavior  of 
the  program:  it  is  an  extensional  security  property  [26]. 

In  the  rest  of  the  paper,  we  present  an  imperative  language  (Section  2), 
formally  define  delimited  release  security  (Section  3),  give  a  security  type  system 
that  provably  enforces  delimited  release  (Section  4),  discuss  a  password-checking 
example  (Section  5),  sketch  related  work  (Section  6),  and  conclude  (Section  7). 


2  A  security-typed  language 

To  illustrate  the  security  model,  we  consider  a  simple  sequential  language,  con¬ 
sisting  of  expressions  and  commands.  The  language  is  similar  to  several  other 
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Fig.  1.  A  general  security  lattice  £  and  the  lattice  Clh 


security-typed  imperative  languages  (e.g.,  [47,4]),  and  its  semantics  are  largely 
standard  (cf.  [48]). 

The  language  syntax  is  defined  by  the  following  grammar: 
e  ::=  val  \  v  |  ei  op  e-i  |  declassify(e,  £) 

c  ::=  skip  |  v  :=  e  |  Ci;  Ci  |  if  e  then  ci  else  c2  |  while  e  do  c 

where  val  ranges  over  values  Val  =  {false,  true,  0,1,...},  ranges  over  variables 
Var,  op  ranges  over  arithmetic  and  boolean  operations  on  expressions,  and  l 
ranges  over  security  levels. 

We  assume  that  the  security  levels  of  data  are  elements  of  a  security  lattice 
C.  The  ordering  specifies  the  relationship  between  different  security  levels.  If 
t\  C  t2  then  information  at  level  i\  is  also  visible  at  level  in-  However,  if  t\  %  i2 
then  information  at  level  is  invisible  at  level  t2.  The  join  operation  (U)  of  £ 
is  useful,  for  example,  for  computing  an  upper  bound  on  the  security  level  of  an 
expression  that  combines  sub-expressions  at  different  security  levels.  An  example 
is  the  security  lattice  C lh  with  two  elements  high  and  low  representing  high  and 
low  confidentiality  levels,  respectively,  with  the  ordering  low  C  high.  A  general 
security  lattice  £  with  a  top  element  T  and  bottom  element  T  is  depicted  in 
Figure  1,  along  with  the  lattice  Clh- 

The  security  environment  r  :  Var  — >  C  describes  the  type  of  each  program 
variable  as  a  security  level.  The  security  lattice  and  security  environment  to¬ 
gether  constitute  a  security  policy,  which  specifies  that  information  flow  from  a 
variable  v\  to  a  variable  Vi  is  allowed  only  if  F{v i)  V  r(v 2).  For  simplicity,  we 
assume  a  fixed  r  in  the  upcoming  formal  definitions. 

The  only  language  expression  that  is  not  standard  is  declassify(e,  £),  a  con¬ 
struct  for  declassifying  the  security  level  of  the  expression  e  to  the  level  l  G  £. 
We  require  that  declassify  expressions  are  not  nested.  At  the  semantic  level, 
declassify(e,  l)  is  equivalent  to  e  regardless  t.  The  intention  is  that  declassifi¬ 
cation  is  used  for  controlling  the  security  level  of  information  without  affecting 
the  execution  of  the  program. 

The  semantics  are  defined  in  terms  of  transitions  between  configurations. 
A  configuration  { M ,  c)  consists  of  a  memory  M  (which  is  a  finite  mapping 
M  :  Var  — >  Val  from  variables  to  values)  and  a  command  (or  expression)  c.  If  c 
is  a  command  (resp.  expression)  then  we  sometimes  refer  to  (M,  c)  as  command 
configuration  (resp.  expression  configuration).  A  transition  from  configuration 


(Mi, ci)  to  configuration  (M2,c2)  is  denoted  by  (Mi,ci)  — >  (M2,  c2).  A  tran¬ 
sition  from  configuration  (M,  c)  to  a  terminating  configuration  with  memory 
M'  is  denoted  by  ( M,c )  — »  M' .  As  usual,  — >*  is  the  reflexive  and  transi¬ 
tive  closure  of  — >.  Configuration  (. M,c )  terminates  in  M'  if  ( M,c )  — >*M', 
which  is  denoted  by  (M,c)  JJ.  M'  or,  simply,  ( M,c )  JJ.  when  M'  is  unimportant. 
We  assume  that  operations  used  in  expressions  are  total,  and,  hence,  expression 
configurations  always  terminate  (denoted  by  (M,  e)  JJ.  val). 

3  A  delimiting  model  for  confidentiality 

The  usual  way  of  defining  confidentiality  is  as  noninterference  [16],  a  security 
property  stating  that  inputs  of  high  confidentiality  do  not  affect  outputs  of  lower 
confidentiality.  Various  definitions  of  noninterference  have  been  used  by  much 
recent  work  on  language-based  security  (e.g.,  [47,  2, 19, 42, 45, 4,  38,  33,  39,  51,  5, 
34]).  However,  noninterference  cannot  characterize  the  security  of  a  program 
that  is  designed  to  release  some  confidential  information  as  part  of  its  proper 
functioning.  We  propose  a  new  confidentiality  characterization  that  delimits  in¬ 
formation  release  and  precludes  laundering  attacks. 

3.1  Noninterference 

Noninterference  is  defined  as  follows  for  programs  written  in  the  language  of  Sec¬ 
tion  2:  if  two  input  memories  are  indistinguishable  for  an  attacker  at  a  security 
level  £  then  the  behavior  of  the  program  on  these  memories  is  also  indistinguish¬ 
able  at  l.  Formally,  two  memories  Mi  and  M2  are  indistinguishable  Mi  =£  M2 
at  level  £  if  Vv.  r(v)  C  f  =>•  Mi(v)  =  M2(v)  (we  assume  a  fixed  r ;  hence  the 
notation  Mi  =g  M2  is  not  parameterized  by  security  environments) .  The  behav¬ 
ior  of  two  program  configurations  (Mi,  ci)  and  (M2,  c2)  is  indistinguishable  at  £ 
(written  (M1,Ci)  (M2,c2))  if  whenever  (M1;c i)  JJ-  M[  and  (M2,c2)  J)  M '2  for 

some  M[  and  M2  then  M[  =i  M!2 .  The  behavior  of  two  expression  configura¬ 
tions  (Mi,ei)  and  (M2,e2)  is  indistinguishable  (written  (Mi,ei)  w  (M2,e2))  if 
(Mi,ei)  JJ.  val  and  (M2,e2)  JJ.  val  for  some  val.  We  are  now  ready  to  formulate 
the  noninterference  security  condition. 

Definition  1  (Noninterference)  Command  c  satisfies  noninterference  if  for 
all  security  levels  £  we  have 


VMi,M2.Mi  =(  M2  =>  (Mi,c)  ( M2,c ) 

While  noninterference  is  a  useful  dependency-based  security  specification,  it  is 
over-restrictive  for  programs  with  declassification.  For  example,  suppose  we  need 
to  intentionally  release  the  parity  of  a  secret  variable  h  in  such  a  way  that  no 
other  information  about  h  is  leaked.  The  program  performing  such  a  release  is 
below: 


l  :=  declassify(parity(h),  low) 


(Par) 


where  r(h)  =  high  and  r(l)  =  low  under  the  lattice  Clh-  In  the  above  sense, 
this  program  is  intuitively  secure.  However,  noninterference  flatly  rejects  the 
program  because  l  does  depend  on  h. 

3.2  Escape  hatches  and  delimited  release 

In  the  example  above,  we  want  to  express  the  requirement  that  only  explicitly  de¬ 
classified  data  but  no  further  information  is  released.  Therefore,  the  specification 
of  security  must  be  relative  to  the  expressions  that  appear  under  declassify 
operators.  These  expressions  can  be  viewed  as  a  part  of  the  security  policy, 
specifying  the  “escape  hatches”  for  information  release.  To  make  this  security 
policy  explicit,  one  could  require  all  escape  hatch  expressions  to  be  declared  in 
a  separate  interface.  Because  this  is  unimportant  for  the  technical  development, 
we  omit  this  requirement.  The  new  security  specification  delimits  information 
release  by  only  allowing  release  through  escape  hatch  expressions: 

Definition  2  (Delimited  release)  Suppose  the  command  c  contains  within 
it  exactly  n  declassify  expressions  declassify(ei,^i), . . . ,  declassify(en,£n). 
Command  c  is  secure  if  for  all  security  levels  £  we  have 

VMi,  M2.  (Afi  =/  M2  &  Vz  G  {*  I  li  C  £}  .  (Mltei)  «  <M2,  e*))  =► 

(Mi ,  c)  (M2,c) 

Intuitively,  this  definition  says  that  for  all  £,  Mi  and  M2  so  that  Mi  =(  M2,  if 
there  is  an  information  leak  through  one  of  the  escape  hatches  e\ , . . . ,  en  observ¬ 
able  at  level  £,  i.e.,  3 i  €  {i  \  £%  E  £}  ■  (Mi,  ef)  76  (M2,  e,),  then  this  leak  is  allowed, 
i.e.,  no  further  conditions  are  imposed.  However,  if  the  difference  between  Mi  and 
M2  is  invisible  at  £  through  all  escape  hatches,  i.e.,  Vz  €  {i  \  £i  E  £}  ■  (M-\ ,  e,j)  rts 
(M2,  e.j),  then  this  difference  must  be  invisible  at  £  through  the  entire  execution 
of  c,  i.e.,  (Mi ,  c)  ( M2,c ). 

One  way  of  interpreting  the  delimited  release  definition  is  that  a  given  pro¬ 
gram  is  secure  as  long  as  updates  to  variables  that  are  later  declassified  occur 
in  a  way  that  does  not  increase  the  information  visible  by  the  attacker  through 
the  escape  hatches.  If  no  variables  used  in  declassification  are  updated  before 
the  actual  declassification,  delimited  release  reduces  to  noninterference.  This 
observation  leads  to  a  simple  way  of  automatically  enforcing  delimited  release, 
reported  in  Section  4. 

It  is  instructive  to  compare  delimited  release  to  noninterference.  Clearly, 
noninterference  is  stronger  than  delimited  release: 

Proposition  1  If  program  c  satisfies  noninterference  then  c  is  secure. 

Furthermore,  for  a  program  without  declassify  primitives  the  two  security 
properties  coincide. 

Proposition  2  If  declassify  primitives  do  not  occur  in  a  secure  program  c 
then  c  satisfies  noninterference. 


3.3  Examples 


The  security  provided  by  delimited  release  can  be  understood  from  some  simple 
examples:  averaging  salaries,  an  electronic  wallet,  and  password  checking. 


Example  1  (Average  salary).  Suppose  variables  hi, . . .  ,hn  store  the  salaries  of  n 
employees.  The  average  salary  computation  is  intended  to  intentionally  release 
the  average  but  no  other  information  about  hi, . . . ,  hn  to  a  public  variable  avg : 


avg  :=  declassify((/ii  +  •  •  •  +  hn)/n,  low)  (Avg) 

We  assume  lattice  Clh  so  that  \/i.r(hi)  =  high  and  r(avg)  =  low.  Clearly 
the  program  does  not  satisfy  noninterference  as  there  is  a  dependency  from 
hi, ...  ,hn  to  avg.  However,  the  nature  of  information  flow  from  high  to  low  is 
limited.  Although  the  low-level  observer  learns  the  average  of  the  secret  inputs, 
it  is  not  possible  to  learn  more  information  about  them.  For  example,  swapping 
the  values  of  hi  and  hj  is  not  visible  at  the  low  level.  Allowing  these  limited 
flows,  the  program  is  accepted  as  secure  by  the  delimited  release  definition. 

On  the  other  hand,  consider  a  laundering  attack  on  program  Avg  that  leaks 
the  salary  of  employee  i  to  avg. 


hi  .  hi, . . .  hn  .  hi, 

avg  :=  declassify  ((hi  +  •  •  •  +  hn)/n,  low) 


(Avg-Attack) 


This  program  does  not  satisfy  delimited  release.  To  see  this,  take  i  =  1,  Mi(hi)  = 
M2(h2)  =  2,  M2(hi)  =  Mi(h2)  =  3,  and  Mi(v)  =  M2(v)  =  0  for  all  variables  v 
different  from  hi  and  h2.  For  £  =  low  we  have  M\  —t  M2  and  (Mi,  ( hi  +  ■  ■  ■  + 
hn)/n )  w  (. M2 ,  (hi  +  -  ■  •  +  hn)/n)  because  both  expression  configurations  evaluate 
to  5/n.  But  (M-| ,  Avg-Attack)  9^  (M2,  Avg-Attack)  because  the  final  value  of 
the  public  variable  avg  is  2  and  3,  respectively,  which  violates  Definition  2. 
Therefore,  the  laundering  attack  is  rejected  as  insecure. 


Example  2  (Electronic  wallet).  Consider  an  electronic  shopping  scenario.  Sup¬ 
pose  h  stores  the  (secret)  amount  of  money  in  a  customer’s  electronic  wallet, 
l  stores  the  (public)  amount  of  money  spent  during  the  current  session,  and  k 
stores  the  cost  of  the  item  to  be  purchased.  The  following  code  fragment  checks 
if  the  amount  of  money  in  the  wallet  is  sufficient  and,  if  so,  transfers  the  amount 
k  of  money  from  the  customer’s  wallet  to  the  spent-so-far  variable  l : 

if  declassify(/i  >  k,  low)  then  ( h  :=  h  —  k\l  :=  l  +  k)  else  skip  (Wallet) 

We  assume  lattice  Clh  so  that  r(h)  =  high  and  r(k)  =  r(l)  =  low.  As  with 
program  Avg,  this  program  fails  to  satisfy  noninterference  but  does  satisfy  de¬ 
limited  release.  Below  is  an  attack  that  abuses  the  declassification  primitive  and 


leaks3  the  secret  variable  h  bit-by-bit  to  l  (assuming  h  is  an  ?z-bit  integer): 


l  :=  0; 

while  (n  >  0)  do 

k  :=  2™_1; 

if  declassify(/i  >  k,  low) 

then  {h  :=  h  —  k\  l  :=  l  +  k)  else  skip; 
n  :=  n  —  1 


(Wallet-Attack) 


where  -T(n)  =  low.  This  is  a  laundering  attack  whose  effect  is  magnified  by  the 
loop.  It  is  not  difficult  to  see  that  the  attack  is  indeed  rejected  by  the  delimited 
release  model. 


3.4  Features  and  extensions 

An  interesting  feature  of  the  delimited  release  is  that  it  forces  the  programmer  to 
be  explicit  about  what  information  is  being  released.  This  is  because  the  security 
policy,  in  the  form  of  expressions  under  declassify,  is  simply  a  part  of  program 
text.  For  example,  consider  the  following  program: 

h  :=  parity (h); 

if  declassify(ft.  =  1,  low)  then  ( l  :=  1;  h  :=  1)  else  ( l  :=  0;  h  :=  0) 

where  F(/i)  =  high  and  r(l)  =  low  under  the  lattice  Clh-  According  to  the 
security  policy  h  =  1,  whether  or  not  the  initial  value  of  h  was  1  is  the  information 
intended  for  declassification.  Instead,  however,  the  low-level  observer  learns  the 
parity  of  the  initial  value  of  h.  This  is  a  laundering  attack,  which  is  rejected  by 
the  delimited  release  model.  To  produce  a  semantically  equivalent  secure  version 
of  the  program  above,  the  programmer  may  rewrite  it  to  the  following  program: 

if  declassify(parity(/i),  low)  then  ( l  :=  1;  h  :=  1)  else  (/  :=  0;  h  :=  0) 

This  is  indeed  a  secure  program  according  to  Definition  2.  That  the  parity  of  h  is 
subject  to  intentional  information  release  is  now  more  evident  from  the  security 
policy  parity(ft). 

The  desire  to  automate  the  above  transformation  leads  to  extensions  based 
on  security  ordering  for  programs.  A  program  c2  is  at  least  as  secure  as  a  program 
Ci  (written  ci  Csec  C2)  if  for  all  security  levels  (.  €  C  and  memories  and  M2  we 
have  whenever  Mi  =(,  M2  and  (M2,ci)  then  (Mi,c2)  ~c  (M2,c2). 

The  intuition  is  that  c2  leaks  no  more  secret  information  than  ci,  hence  the 
security  ordering.  It  is  straightforward  to  see  that  security  ordering  Csec  is  a 
preorder  (reflexive  and  transitive).  In  the  partial  order,  formed  by  equivalence 
classes  of  Csec,  programs  satisfying  noninterference  belong  to  the  top-security 
class  (in  the  sense  that  the  other  programs  are  strictly  less  secure).  A  decidable 

3  Furthermore,  this  attack  compromises  the  integrity  of  the  customer’s  wallet  variable. 
However,  this  is  orthogonal  to  the  confidentiality  issues  dealt  with  in  this  paper. 


approximation  of  this  security  ordering  for  driving  security-enhancing  program 
transformation  is  an  attractive  direction  for  future  work. 

The  delimited  release  model  has  some  limitations  in  describing  security  poli¬ 
cies  for  information  release,  because  all  of  the  declassified  expressions  are  as¬ 
sumed  to  be  released.  The  model  does  not  permit  the  expression  of  a  security 
policy  in  which  information  should  be  released  only  under  certain  conditions. 
For  example,  consider  a  program  that  leaks  either  hi  or  h2,  but  not  both: 

if  l  then  l  :=  declassify  (hi,  low)  else  l  :=  declassify  (h2,  low) 

where  r(hi)  =  r(h2)  =  high  and  r{l)  =  low  under  the  lattice  C^h-  This 
program  is  secure  according  to  Definition  2.  Both  hi  and  h2  appear  under 
declassify,  which,  according  to  Definition  2,  means  that  the  program  might 
leak  the  values  of  both.  The  requirement  that  only  one  of  the  two  variables  is 
released  cannot  be  expressed  using  Definition  2.  However,  delimited  release  can 
be  enhanced  with  disjunctive  policies  for  representing  finer  policies  as,  e.g.,  “ei¬ 
ther  hi  or  h2  can  be  released  but  not  both.”  Moreover,  delimited  release  can  be 
integrated  with  techniques  based  on  who  controls  information  release,  such  as 
robust  declassification  [50,49,30].  This  integration  can  help  specify  whether  the 
decision  on  which  of  hi  and  h2  can  be  released  may  or  may  not  be  in  the  hands 
of  an  attacker.  A  remark  on  the  combination  of  delimited  release  and  robust 
declassification  follows  in  Section  7. 

4  A  security  type  system  for  delimited  release 

This  section  presents  a  type  system  that  statically  enforces  security.  The  typing 
rules  are  displayed  in  Figure  2.  The  general  form  of  typing  for  an  expression  is 
r  h  e  :  t,  D  meaning  that  an  expression  e  has  type  i  and  effect  D  under  an 
environment  r.  Typing  for  commands  has  the  form  r,pc  he:  U,D  meaning 
that  a  command  c  is  typable  with  effects  U  and  D  under  an  environment  r  and 
a  program  counter  pc.  Program  counters  range  over  security  levels;  they  help 
track  information  flow  due  to  control  flow.  A  program  counter  records  a  lower 
bound  on  the  security  level  of  variables  assigned  in  a  given  program.  The  type 
system  guarantees  that  if  there  is  branching  (as  in  if  and  while  commands)  on 
data  at  level  t  then  the  branches  must  be  typable  under  a  program  counter  at 
least  at  l,  preventing  leaks  via  assignments  in  the  branches. 

Besides  tracking  information  flow  through  assignments  and  control  flow  (in 
the  spirit  of  [11,47]),  the  type  system  collects  information  about  what  variables 
are  used  under  declassification  (which  is  recorded  in  the  effect  D  of  an  expression 
or  a  command)  and  what  variables  are  updated  by  commands  (which  is  recorded 
in  the  effect  U  of  a  command).  For  example,  the  D  effect  of  a  declassify(e,  £) 
expression  is  the  set  of  variables  appearing  in  e,  written  as  Vars(e).  The  key 
restriction  guaranteed  by  the  type  system  is  that  variables  used  under  declassifi¬ 
cation  may  not  be  updated  prior  to  declassification.  This  restriction  is  enforced 
in  the  rules  for  the  sequential  composition  and  the  while  loop.  The  overall  pro¬ 
gramming  discipline  enforced  by  the  type  system  ensures  that  typable  programs 
are  secure,  which  is  formalized  by  the  following  theorem. 


r  b  val  :  l,  0 


r(v)  =  i 
r  \~  v  :  £,$ 

r  e  :  l,  D\  r  b  e'  :  £,  Do 
F  \~  e  op  e'  :  Di  U  D2 

r  \~  e  :  £,  D 

F  b  declassify(e,  £')  :  (! ,  Vars(e) 

r  \-  e :  £,  d  ene’ 
r\-e:£’,D 

F,  pc  \~  skip  :  0,  0 

r  \~  e  :  £,  D  £u  pc  C.  F(v) 

F,pc  b  v  :=  e  :  {u},  D 

r,  pc  b  Ci  :  Ui,  D\  F,  pc  b  C2  :  U2 ,  D2  Ui  fl  D2  =  0 
r,  pc  b  ci;  C2  :  Ui  U  U2,  D\  U  D2 

I  b  e  :  £,  D  F,  £  U  pc  b  ci  :  U\,  D\  r,  t  U  pc  b  C2  :  ^2 

-T,  pc  b  if  e  then  ci  else  C2  :  Ui  U  U2,  D  U  D\  U  D2 

r\-e:£,D  F,  £  \J  pc  c  :  Ui,D\  Ui  l~l  (D  U  D\)  =  0 
r.  pc  b  while  e  do  c  :  Ui ,  D  U  D\ 

r,pc  be:  U,  D  pc'  C.  pc 
r, pc' he:  U,  D 


Fig.  2.  Typing  rules 


Theorem  1.  r,  pc  b  c  :  U ,  D  =>•  c  is  secure. 

A  proof  by  induction  on  the  typing  derivation  is  sketched  in  the  appendix. 

Note  that  the  type  system  is  more  restrictive  than  necessary  to  enforce  the 
security  condition.  For  example,  consider  the  program 

h  :=  parity  (ft);  l  :=  declassif  y(/i,  low) 

where  r(h)  =  high  and  r(l)  =  low  under  the  lattice  £lh-  Although  h  is  updated 
prior  to  declassification,  the  entire  program  actually  leaks  only  the  parity  of  the 
initial  value  of  h,  which  is  less  information  than  the  complete  initial  value  of  h 
leaked  by  the  declassifying  assignment  alone.  Indeed,  according  to  Definition  2 
the  program  is  secure;  however,  it  is  rejected  by  the  type  system.  Devising  a  more 
permissive  type  system  for  enforcing  the  delimited  release  security  condition  is 
a  worthwhile  topic  for  future  work. 

5  A  password-checking  example 

This  section  applies  the  delimited  release  model  to  password  checking,  illustrat¬ 
ing  how  the  type  system  gives  security  types  to  password-checking  routines  and 
also  prevents  laundering  attacks. 

We  consider  UNIX-style  password  checking  where  the  system  database  stores 
the  images  (or  the  hashes)  of  password-salt  pairs.  Salt  is  a  publicly  readable 
string  stored  in  the  database  for  each  user  id,  as  a  protection  against  dictionary 
attacks.  For  a  successful  login,  the  user  is  required  to  provide  a  query  such  that 
the  hash  of  the  string  and  salt  matches  the  image  from  the  database. 

Below  are  typed  expressions/programs  for  computing  the  hash,  matching 
the  user  input  to  the  password  image  from  the  database,  and  updating  the 
password.  We  use  arrows  in  types  for  expressions  to  indicate  that  under  the 
types  of  the  arguments  on  the  left  from  the  arrow,  the  type  of  the  result  is  on  the 
right  from  the  arrow.  The  expression  hash (pwd,  salt)  concatenates  the  password 
pwd  with  the  salt  salt  and  applies  the  one-way  hash  function  buildHash  to  the 
concatenation  (the  latter  is  denoted  by  ||).  The  result  is  declassified  to  the  level 
low. 


r  h  hash  (pwd,  salt)  :  £pwd  x  £sait  — >  low 

=  declassify(buildHash(pu>(i| \salt),  low) 

The  expression  mat  ch(pwdlmg ,  salt,  query)  checks  if  the  password  image  pwdlmg 
is  equal  to  the  hash  of  the  user  query  query  with  the  salt  salt. 

r  b  match  {pwdlmg,  salt,  query)  :  tpwdimg  x  £sait  x  lquery  — >  £Vwdimg  LI  low 
=  ( pwdlmg  =  hash  (query,  salt)) 

Notice  that  the  expression  is  typable  only  if  the  security  level  of  the  result  is  no 
less  confidential  than  both  the  security  level  of  pwdlmg  and  low.  The  program 


update (pwdlmg,  salt,  oldPwd,  newPwd)  updates  the  old  password  hash  pwdlmg 
by  querying  the  old  password  oldPwd,  matching  its  hash  to  pwdlmg  and  (if 
matched)  updating  the  hashed  password  with  the  hash  of  newPwd. 

r,  (-pwdlmg  b  updat e(pwdlmg,  salt,  oldPwd ,  newPwd)  (low  C  ( pwdlmg ) 

=  if  match  (pwdlmg,  salt,  oldPwd) 

then  pwdlmg  =  hash  (newPwd,  salt) 

else  skip 

Let  us  instantiate  the  typings  above  for  the  lattice  Clh  and  show  that  they 
capture  the  desired  intuition. 

—  The  honest  user  applying  hash  to  a  password  and  salt: 
r  b  hash (pwd,  salt)  :  high  x  low  — >  low. 

—  The  attacker  hashing  a  password  with  the  honest  user’s  public  salt: 
r  b  hash  (pwd,  salt)  :  low  x  low  — >  low. 

—  The  honest  user  matching  a  password: 

r  b  ma.tch(pwdlmg ,  salt,  query)  :  low  x  low  x  high  — >  low. 

—  The  attacker  attempting  to  guess  a  password  by  matching  it  to  a  legitimate 
password  image  and  salt: 

r  b  match  (pwdlmg,  salt,  query)  :  low  x  low  x  low  — ■>  low. 

—  The  honest  user  modifying  a  password: 

r,  low  b  updat e(pwdlmg,  salt,  oldPwd,  newPwd)  :  low  x  low  x  high  x  high. 

—  The  attacker  attempting  to  modify  the  honest  user’s  password: 

r,  low  b  updat e(pwdlmg ,  salt,  oldPwd,  newPwd)  :  low  x  low  x  low  x  low. 

These  are  all  typable  and  hence  secure  programs.  The  rationale  for  considering 
these  programs  secure  is  that  to  succeed  the  attacker  needs  to  guess  the  password, 
which  is  unlikely  given  a  large  password  space  and  little  prior  knowledge. 

That  the  programs  are  typable  guarantees  that  the  password-checking  mech¬ 
anism  is  not  vulnerable  to  laundering  attacks.  For  example,  consider  an  attack 
that,  similarly  to  Wallet-Attack,  launders  bit-by-bit  the  secret  variable  h  to  l 
(assuming  h  is  an  n-bit  integer)  via  the  declassification  mechanism  that  is  built 
in  the  hash  expression. 

I  :=  0; 

while  (n  >  0)  do 

k  :=  2n~1; 

if  hash(sign(/i  —  k  +  1),0)  =  hash(l,  0) 
then  (h  :=  h  —  k;  l  :=  l  +  k)  else  skip; 

n  :=  n  —  1 

where  r(k)  =  r(l)  =  r(n)  =  low,  r(h)  =  high  and  sign  returns  1,  —1  or  0  if  the 
argument  is  positive,  negative,  or  0,  respectively.  That  this  attack  might  indeed 
leak  h  in  a  bit-by-bit  fashion  is  easy  to  see  because  the  inequality  h  >  k  holds 
if  and  only  if  the  inequality  h  —  k  +  1  >0  holds,  which,  for  a  sensible  hashing 
algorithm,  is  likely  to  be  equivalent  to  hash(sign(/i  —  k  +  1) ,  0)  =  hash(l,0). 


Clearly,  the  program  above  is  insecure  according  to  Definition  2.  Notice  that 
the  program  is  rightfully  rejected  by  the  type  system.  This  is  because  variable  h 
both  occurs  under  declassification  and  is  updated  in  the  body  of  the  loop. 

Furthermore,  observe  that  programs  Avg  and  Wallet  are  typable  whereas 
attacks  Avg-Attack  and  Wallet-Attack  are  rejected  by  the  type  system. 

6  Related  work 

Policies  for  intentional  information  release  have  been  an  active  area  of  research. 
Cohen’s  selective  (in) dependence  [8]  security  definition  can  be  viewed  as  a  pre¬ 
cursor  for  our  work.  Cohen’s  definition  is  based  on  partitioning  the  secret  input 
domain  into  subdomains  requiring  noninterference  when  secret  variables  are  re¬ 
stricted  to  each  subdomain.  For  example,  program  Par,  revealing  the  parity  of  h 
to  /,  satisfies  selective  independence  with  respect  to  the  partitioning  of  the  do¬ 
main  of  integers  for  h  into  odd  and  even  numbers.  However,  the  security  policy  of 
specifying  what  can  be  leaked  relies  on  a  semantic  specification  of  subdomains. 
Recent  incarnations  of  selective  independence  based  on  abstract  variables  [20], 
equivalence  relations  [39] ,  and  abstract  noninterference  [14]  also  need  to  be  spec¬ 
ified  at  the  semantic  level.  In  contrast,  our  escape  hatches  facilitate  a  syntactic 
way  of  specifying  selective  independence:  two  values  are  in  the  same  subdomain 
if  and  only  if  the  results  of  evaluating  the  expression  under  each  declassify 
primitive  on  these  two  values  are  the  same  values.  Moreover,  the  escape  hatches 
provide  the  flexibility  to  condition  the  release  of  information  on  public  values  (cf. 
program  Wallet),  which  cannot  be  represented  by  the  original  definition  of  selec¬ 
tive  independence.  Finally,  the  syntactic  escape-hatch  policy  mechanism  leads 
us  to  a  security  type  system  that  enforces  security,  whereas  there  appears  no  au¬ 
tomatic  enforcement  mechanisms  for  (any  variation  of)  selective  independence. 

Further  related  work  is  grouped  into  categories  of  how  information  is  released, 
how  much  information  is  released,  and  relative  to  what  information  is  released. 
For  a  more  detailed  overview  of  this  area  we  refer  to  a  recent  survey  [37]. 

How?  A  common  approach  to  relaxing  noninterference  to  account  for  intentional 
information  release  is  based  on  intransitive  noninterference  [36,  32,  35,  24],  which 
originated  from  early  work  on  conditional  noninterference  [16, 17].  Mantel  and 
Sands  have  recently  addressed  intransitive  noninterference  in  a  language-based 
setting  [25] .  Intransitive  flows  in  the  context  of  declassification-sensitive  unwind¬ 
ing  have  been  explored  by  Bossi  et  al.  [6].  Intransitive  noninterference  accommo¬ 
dates  policies  where  information  might  flow  intransitively,  e.g.,  from  level  £\  to  £2 
and  from  £2  to  £3  but  not  from  £\  to  £3  directly.  The  goal  is  that  information  may 
only  be  declassified  if  it  passes  through  a  special  declassifier  security  level.  The 
assurance  provided  by  this  approach  is  that  portions  of  computation  between 
declassification  actions  are  in  a  certain  sense  secure.  However,  no  guarantees  are 
given  for  the  entire  computation.  Myers  and  Liskov’s  decentralized  model  [28, 
29]  offers  security  labels  in  which  selective  declassification  [33]  is  permitted  on 
the  basis  of  a  static  analysis  of  process  authority  and  relationships  between 


principals.  Security  labels  have  additional  structure  that  describes  the  entities 
capable  of  performing  declassification.  While  the  above  policies  help  express  how 
information  is  released,  they  fail  to  account  for  what  has  been  released.  In  par¬ 
ticular,  neither  intransitive  noninterference  nor  selective  declassification  directly 
prevents  laundering  attacks. 


How  much?  A  quantitative  approach  to  information  flow  gives  bounds  on  how 
much  information  may  be  released.  For  instance,  this  is  useful  for  measuring 
how  much  information  about  the  password  is  revealed  on  a  login  attempt  during 
password  checking.  Based  on  Shannon’s  information  theory  [41],  early  ideas  of 
quantitative  security  go  back  to  Denning’s  work  [10]  which,  however,  does  not 
provide  automated  tools  for  estimating  the  bandwidth.  Clark  et  al.  [7]  propose 
syntax-directed  inference  rules  for  computing  estimates  on  information  flow  re¬ 
sulted  from  if  statements  in  an  imperative  language.  Recent  line  of  work  by 
Di  Pierro  et  al.  [12]  suggests  approximate  noninterference,  which  can  be  thought 
of  as  noninterference  modulo  probabilistically  specified  “noise”  In  a  process- 
algebra  setting,  Lowe’s  quantitative  definition  of  information  flow  [23]  measures 
the  capacity  of  information  flow  channels.  However,  tracking  the  quantity  of  in¬ 
formation  through  program  construct  appears  to  be  a  daunting  task.  To  date, 
there  appears  no  static  analysis  with  reasonably  permissive  rules  for  while  loops. 


Relative  to  what?  In  the  rest  of  this  section,  we  discuss  models  for  information 
release  relative  to  the  attacker’s  power  to  observe  and  affect  declassification.  Vol- 
pano  and  Smith  [46]  have  proposed  a  type  system  that  allows  password-matching 
operations  and  with  the  security  assurance  that  (i)  no  well-typed  program  can 
leak  secrets  in  polynomial  (in  the  length  of  the  secret)  time,  and  (ii)  secret  leaks 
are  only  possible  with  a  negligible  probability.  In  subsequent  work  [44],  Volpano 
proves  that  leaking  passwords  in  a  system  where  passwords  are  stored  as  im¬ 
ages  of  a  one-way  function  is  not  easier  than  breaking  the  one-way  function. 
Both  of  these  studies  are,  however,  tailored  to  the  password-checking  scenario. 
Abadi  gives  a  type  system  [1]  in  which  declassification  is  connected  to  uses  of 
encryption,  for  a  calculus  of  cryptographic  protocols,  the  spi  calculus  [3].  Secret 
keys  and  their  usage  are  hidden  by  the  security  definition,  allowing  the  result 
of  encryption  to  be  considered  publicly  visible.  Sumii  and  Pierce  [43]  employ 
relational  parametricity  techniques  for  reasoning  about  cryptographic  protocols 
involving  encryption.  Laud’s  complexity-theoretic  security  definition  [21,22]  is 
also  specific  to  declassification  by  encryption.  This  security  definition  ensures 
that  a  polynomial-time  (in  the  length  of  the  secret)  adversary  in  an  imperative 
language  is  not  able  to  leak  secrets  by  abusing  the  encryption-based  declassifi¬ 
cation  mechanism. 

The  idea  underlying  Dam  and  Giambiagi’s  admissibility  [9, 15]  is  that  the 
implementation  of  a  specification  satisfies  admissibility  if  there  are  no  other 
information  flows  than  those  described  in  a  confidentiality  policy  of  the  specifi¬ 
cation.  The  relativity  of  information  release  here  is  with  respect  to  information 
release  in  the  specification. 


Finally,  Zdancewic  and  Myers  have  proposed  a  security  condition  called  ro¬ 
bust  declassification  [50] ,  which  captures  the  idea  that  an  attacker  may  not  learn 
more  information  than  intended.  The  key  idea  is  that  attacker-controlled  com¬ 
putation  is  not  allowed  to  increase  observations  about  secrets  by  causing  misuse 
of  the  declassification  mechanism.  Robust  declassification  ensures  that  an  ac¬ 
tive  attacker  (who  can  affect  system  behavior)  cannot  learn  anything  more  than 
a  passive  attacker  (who  may  only  observe  the  system’s  behavior).  Zdancewic 
has  proposed  a  type  system  [49]  intended  to  enforce  robust  declassification.  Re¬ 
cently,  Myers  et  al.  [30]  have  generalized  robust  declassification  as  an  enforceable 
end-to-end  security  property  and  introduced  qualified  robustness  that  provides 
untrusted  code  with  a  limited  ability  to  affect  information  release. 

7  Conclusion 

We  have  presented  a  security  model  for  intentional  information  release.  Because 
this  model  delimits  information  flow  by  explicit  policies,  we  are  able  to  capture 
what  information  is  released  as  opposed  to  how  it  is  released.  This  approach  en¬ 
ables  us  to  track  laundering  attacks  that  are  often  undetectable  by  other  models 
of  information  flow.  Much  work  on  information  flow  relies  on  compartmental- 
ization  (creating  special  security  levels,  or  compartments,  for  data  to  restrict 
information  flow)  to  fence  against  laundering  attacks.  However,  as  we  have  seen 
from  the  average-salary,  electronic- wallet,  and  password-checking  examples,  com- 
partmentalization  is  not  a  panacea.  Our  model  can  be  viewed  as  another  line  of 
defense  that  prevents  attacks  missed  by  compartmentalization. 

The  delimited  release  model  is  in  some  ways  orthogonal  to  robust  declassifi¬ 
cation  [50];  the  former  controls  what  may  be  declassified,  and  the  latter  ensures 
that  the  attacker  cannot  control  decisions  about  when  it  is  declassified.  A  syn¬ 
thesis  of  these  security  definitions  in  a  language-based  setting  would  further 
improve  assurance  that  information  is  being  released  properly.  Delimited  release 
also  opens  up  possibilities  for  using  security- typed  languages  such  as  Jif  [27,  31] 
to  write  components  of  larger  systems  written  in  more  conventional  languages 
such  as  Java  [18].  Delimited  release  security  could  guarantee  that  security-critical 
Jif  code  wrapped  into  Java  programs  would  not  disclose  more  information  than 
is  released  by  the  Jif  code  alone. 
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Appendix 

This  appendix  presents  a  proof  of  Theorem  1. 

Theorem  1.  r,  pc  h  c  :  U ,  D  ==>  c  is  secure. 

Proof.  We  sketch  a  proof  by  induction  on  the  typing  derivation  for  c.  With  the 
exception  of  the  straightforward  case  for  the  subsumption  rule  (in  the  bottom 
of  Figure  2),  the  induction  is  on  the  structure  of  c.  Suppose  c  contains  exactly  n 
declassify  expressions  declassify(ei,  Li), . . . ,  declassify(e„, £n).  Suppose  that 
for  some  security  level  £  and  memories  Mi  and  M2  where  Mi  =n  M2,  we  have 
Vz  €  {i  |  Li  C  L}  .  ( Mi,ei )  ~  (M2,ej).  We  need  to  show  (M1;c)  (M2,c).  We 

assume  that  (Mi,c)  JJ.  M[  and  (M2,c)  1)  M2  for  some  M[  and  M 2  (the  relation 
is  obvious  if  one  of  the  configurations  diverges).  It  remains  to  be  shown  that 
M[  =t  M2. 

skip  Straightforward,  because  M[  =  M\  =e  M2  =  M!2. 

v  :=  e  Clearly,  M[  =1  Mi  =1  M2  —n  M '2  in  case  r(v)  %  t.  In  case  r(v)  Q  l, 
the  typing  rule  for  assignments  ensures  that  the  security  levels  of  variables 
occurring  in  e — outside  declassify  primitives — are  below  L.  Hence  the  val¬ 
ues  of  these  variables  are  the  same  in  both  Mi  and  M2.  That  the  values  of 
expressions  under  declassify  primitives  are  the  same  in  both  M\  and  M2 
is  guaranteed  by  the  assumption  Vz  €  {i  \  Li  C  L}  .  (Mi,  ef)  w  (M2,  e,).  (Note 
that  declassification  to  level  £j  for  some  j  so  that  Lj  %  t  is  not  allowed  by 
the  typing  rule  for  assignments.)  To  sum  up,  the  values  of  variables  outside 
declassification  primitives  are  the  same  in  both  Mi  and  M2  and  so  are  the 
values  of  expressions  under  declassify.  Clearly,  the  application  of  op  op¬ 
erations  to  the  subexpressions  gives  the  same  results  for  both  Mi  and  M2. 
Therefore,  M[  =(  M2. 


ci ;  C2  By  the  typing  rule  for  sequential  composition,  both  ci  and  C2  must  be 
typable.  The  set  I  =  {i  \  ti  Z  l  &  declassify^,  f!j)  occurs  in  c}  can  be 
viewed  as  the  union  of  7i  =  {*  |  ii  Z  i  &  declassify(e.j,  if)  occurs  in  Ci} 
and  I2  =  {*  |  ^  Z  i  &  declassify(e.j, if)  occurs  in  C2}.  As  (Mi,ci;c2)  1| 
M[  and  (M2,c-i-;c2)  I|  M2  there  are  M "  and  M If  so  that  (Mi,c  1)  1|  M" 
and  (M2, Ci)  1|  Mf.  Because  /1  C  /,  we  can  apply  the  induction  hypothesis 
to  Ci.  We  receive  M"  =n  Mf ■  In  order  to  show  M[  =1  M!2  we  would  like 
apply  the  induction  hypothesis  to  C2.  However,  this  requires  that  we  demon¬ 
strate  Vi  £  I2 •  ( M",Ci )  w  (Mf,ei),  which  is  different  from  what  we  know 
(Vi  £  I 2 •  (Mi,  ef)  ~  (M2,  e»)).  But  because  the  effect  system  ensures  that  no 
variable  used  in  {ei}iS/2  is  updated  by  ci,  we  infer  that  for  any  variable  v 
such  that  v  occurs  in  {ej}i6/2  we  have  Mi(v)  =  M”(v)  and  M2(v)  =  M”(v). 
This  assures  Vi  £  I2 ■  ( M",e* )  w  (Mj  ,  e*),  and  hence,  by  the  induction  hy¬ 
pothesis, 

if  e  then  ci  else  C2  Suppose  r  h  e  :  (! ,  D'  for  some  V  and  D' .  In  case  %  i, 
the  pc-based  mechanism  of  the  type  system  ensures  that  only  variables  at  or 
above  l'  may  be  assigned  to  in  Ci  and  C2.  Thus,  there  are  no  assignments  to 
variables  at  i  or  below  in  either  ci  or  C2.  Hence  the  memories  Mi  and  M2  are 
unaffected  below  t  throughout  the  execution,  which  results  in  M(  =#  M(. 

If  C  £,  then,  because,  Vi  £  {i  |  ii  Q  (.}  ■  (Mi,d)  «  (M2,ei),  including 
all  occurrences  of  under  declassify  in  e,  we  have  ( Mi,e )  1|  val  and 
(M2,e)  1|  val  for  some  val.  Hence,  for  both  Mi  and  M2,  the  computation 
will  take  the  same  branch,  i.e.,  ci,  if  val  =  true,  or  C2  otherwise.  That 
M[  =£  M2  follows  by  the  application  of  the  induction  hypothesis  to  Ci  or  C2, 
respectively. 

while  e  do  ci  Suppose  rhe:f,D'  for  some  £'  and  D' .  Case  (!  %  l  is  resolved 
in  the  same  fashion  as  for  if.  If  £'  Z  l,  then 


Vi  G  {i  I  £i  Z  £}  .  (Mi,ei)  «  (M2,  Bi) 

which  includes  all  occurrences  of  e,  under  declassify  in  e.  Therefore,  we 
have  (. Mi,e )  1|  val  and  (M2,e)  J|  val  for  some  val.  Hence,  for  both  Mi 
and  M2,  either  the  computation  proceeds  with  d,  if  val  =  true ,  or  termi¬ 
nates  otherwise.  Because  the  while  loop  terminates  for  both  Mi  and  M2, 
the  computation  can  be  represented  as  a  sequential  composition  of  a  series 
of  d  commands.  This  case  reduces  to  consequently  applying  the  sequential 
composition  case.  Note  that  e  keeps  evaluating  to  the  same  value  under  both 
Mi  and  M2  after  each  iteration  (the  effect  system  ensures  that  no  variable 
used  under  declassify  is  updated  by  d).  Hence,  when  e  becomes  false,  the 
loop  terminates  after  executing  the  same  number  of  d  commands  for  Mi  and 
M2.  This  implies  M[  =n  M2.  □ 


